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INTRODUCTION 


The  thesis  falls  into  two  major  parts.  In  the  first 
oart  I discuss  the  concept  of  demons,  event-driven 
procedures  which  appear  to  run  concurrently  with  the 
processes  they  are  monitorinq.  In  the  second  portion  of 
the  thesis  I discuss  a system  for  alertinq  on  network 
databases  called  SANDL  and  its  precursor,  LDEMON. 

Some  important  points  that  will  be  examined  are  the 
sharability  of  databases,  with  accessinq  and  updatinq 
functions  that  are  conceived  as  messaqe  handlers,  (the 
requirement  of  sharability  beinq  oart  of  the 
justification  of  an  alerter  system  in  the  first  place)  as 
well  as  the  functional  framework  for  the  data  base 
accessinq  and  updatinq  functions  and  their  implications, 
and  the  modifiability  of  the  schema  which  qives  the  user 
the  power  to  define  new  record  classes  and  demons  at  will 
while  the  system  is  runninq  on-line. 

Demons  should  be  thouqht  of  in  the  context  of 
whether  knowledqe  is  synthesized  in  terms  of  qoals  or  in 
terms  of  data.  At  first  siqht  this  distinction  miqht 
seem  more  appropriate  to  an  artificial  intelliqence 
application  such  as  computer  vision,  but  in  fact  it  is  a 
relevant  issue  for  data  base  technoloqy,  where  the 
interest  is  not  in  acquirinq  an  under  stand inq  of  some 
scene,  but  in  forminq  an  intelliqent  appraisal  of  the 
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current  state  of  affairs  represented  by  the  data  base. 
Goal-driven  activities  in  artificial  intelligence 
applications  tend  to  deal  with  hypothesis  formulation,  a 
sort  of  top-down  dividinq  and  conquering  of  the  problem. 
Most  well-structured  programs  outside  the  domain  of 
artificial  intelligence  can  be  put  into  this  framework. 
Data  or  event-driven  activities  (no  distinction  between 
what  is  and  what  changes  is  necessary  here)  tend  to  be 
bottom-up,  in  the  sense  that  it  is  the  input  data  which 
proposes  the  way  in  which  it  should  be  handled.  A good 
example  outside  of  artificial  intelligence  is  an 
intepreter,  where  it  is  the  input  that  tells  the  system 
what  to  do  next.  Demons,  which  monitor  their 
preconditions  and  take  action  when  these  preconditions 
become  true,  are  one  possible  implementation  of  an 
event-driven  system. 

Bobrow  and  Norman  (1975)  point  out  that  driving  an 
automobile  is  a paradiqm  for  an  event-driven  activity. 
Even  thouqh  the  strateqy  of  a car  trip  may  be  planned  in 
advance  to  have  a certain  destination  and  route,  the 
tactics  of  driving  are  largely  event-driven  and 
concurrent  with  a host  of  other  activities  - looking  at 
the  scenery,  talking,  and  so  on.  Most  of  the  activity  of 
driving  follows  in  response  to  changes  in  the  data,  for 
which  no  plans  could  be  made  in  advance. 
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How  does  this  distinction  relate  to  databases? 
Ordinarily  we  expect  a data  management  system  to  be 
preprogrammed  to  respond  to  some  few  types  of  requests, 
e.g.  what  is  the  name  of  so-and-so,  change  the  balance 
of  this  account  in  this  way,  etc.  Rarely  is  a user  able 
to  program  the  system,  only  to  command  it.  If  he  should 
want  to  observe  changes  in  the  data  he  has  no  recourse 
except  to  make  the  same  query  again  and  again.  The 
object  of  the  research  on  alerters  here  reported  is  to 
enable  users  to  ask  questions  like: 

"Report  the  name  of  any  subscriber  who  changes  hie 
address . " 

or  "Give  a warning  if  a ship  is  too  low  on  fuel  to 
reach  a destination." 

or  "Report  if  any  department  has  more  employees  out 

sick  than  the  average."’ 

or  "Take  corrective  action  if  any  bank  balance  falls 

below  zero  dollars." 

These  are  just  a few  representative  examples  of  a 
common  management  problem.  A bank  may  wish  to  monitor 
the  profitability  and  financial  health  of  companies  to 
which  it  had  lent  money,  or  a company  may  want  to  keep 
constant  track  of  size  of  inventories  versus  sales. 


r 

jj 
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Alerters  provide  an  answer  whenever  the  manager  has  the 
need  to  dynamically  supply  the  conditions  to  be 
monitored. 
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Guarded  Commands 

Dijkstra  has  presented  a new  formalism  for 
nondeterministic  proqrams  which  is  particularly  well 
suited  to  proofs  of  correctness  and  termination.  He 
notes  that  a number  of  deterministic  oroqrams  may  be 
mapped  into  a sinqle  nondeterministic  program  which  has 
the  same  effect.  In  order  to  do  this,  Dijkstra  invents  a 
syntax  for  the  quarded  command,  which  is  a list  of 
statements  preceded  by  a Boolean  expression.  If  the 
Boolean  expression  is  true,  the  guarded  command  may  be 
executed,  but  need  not  be. 

The  syntax  orovides  for  a repetitive  construction 
and  an  alternative  construction,  which  are  the 
nondeterministic  equivalents  of  do-loops  and 
if-statements  and  both  of  which  are  guarded  command 
lists,  i.e.  lists  of  guarded  commands  any  one  of  which 
may  be  executed  if  its  guard  is  true.  In  the  alternative 
construction  if  any  guard  is  true  its  guarded  command  may 
be  executed  and  at  least  one  of  them  will  be  executed. 
If  no  guard  is  true  the  alternative  construction 
terminates  with  an  error.  The  repetitive  construction  on 
the  other  hand  executes  any  guarded  command  whose  guard 
is  true  until  no  guard  is  true,  at  which  ooint,  the 
repetitive  construction  terminates  successfully.  It  is 
this  repetitive  construction  which  is  important  in  the 


Paqe  6 


discussion  of  demons. 

Two  important  ideas  can  be  taken  from  Dijkstra's 
article.  First,  there  is  the  notion  that  the  quarded 
command,  like  critical  sections  in  operatinq  systems,  can 
be  used  to  specify  that  no  other  activity  can  interrupt 
durinq  the  execution  of  the  statements  in  the  quarded 
command.  This  corresponds  to  the  reauirement  that  demons 
must  be  blocked  from  executinq  durinq  the  middle  of  an 
update  (unless  they  are  FAIL  demons) , otherwise  the 
obvious  cyclinq  occurs.  For  example  if  a demon  is 
monitoring  the  credits  and  debits  of  a balance  sheet, 
there  will  always  be  some  point  durinq  the  middle  of  an 
update  when  the  credit  and  debit  figures  do  not 
correspond,  and  the  demon  must  be  prevented  from 
prematurely  taking  action. 

Secondly,  guarded  commands  provide  a formalism  for 
demons  that  abstract  away  from  specific  deterministic 
implementations.  Informally,  the  set  of  demons  can  be 
taken  as  guarded  commands  in  the  do  od  repetitive 
construction  which  attempts  to  execute  any  one  the 
quarded  commands  until  no  quard  is  true. 


Demons  in  Lanquaqes  foe  Artificial  Intelliqence 

In  PLANNER  the  basic  deductive  mechanism  is  the 
"theorem",  which  consists  of  two  Darts:  a pattern  to  be 
matched,  and  a proqram.  The  lanquaqe  supports  three 
types  of  theorems:  "consequent",  "antecendent" , and 
“erase".  The  consequent  theorem  is  closest  to  usual 
proqramminq  techniques  since  the  pattern  to  be  matched  is 
considered  proven  if  the  proqram  of  the  theorem  executes 
successfully.  Essentially,  this  is  little  different  from 
the  manner  in  which  a proqram  executes  successfully  only 
when  all  its  subroutines  run  to  completion.  The  THGOAL 
primitive  acts  somewhat  like  a CALL  statement  of  FORTRAN 
or  PL/1  with  a qood  deal  more  soph i st icat ion . THGOAL 
attempts  to  find  its  arqument  (a  pattern)  in  the 
database,  but  if  the  search  for  an  assertion  which 
matches  the  pattern  fails,  THGOAL  tries  to  execute 
consequent  theorems  which  match  the  pattern  until  one 
succeeds  and  the  pattern  is  "proven". 

The  antecedent  and  erase  theorems  operate  in  a 
distinctly  different  manner.  The  proqram  for  an 
antecedent  theorem  is  invoked  whenever  an  assertion 
matchinq  its  Pattern  is  asserted.  In  this  case  thn 
antecedent  theorem  is  directed  by  an  event,  the  addition 
of  an  assertion,  which  is  the  essential  character istic  of 
a demon.  Correspondinqly,  an  erase  theorem  monitors 
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deletion  of  assertions  which  match  its  pattern  and  then 
executes  its  Droqtam.  Antecedent  and  erase  theorems  are 

I customarily  used  to  add  and  delete  assertions  which  are 

implied  by  the  assertion  which  matches  the  pattern. 

QLISP  has  a more  qeneral  method  for  handlinq  which 
allows  teams  of  demons  to  be  set  up  that  will  be  invoked 
upon  any  storage  or  retrieval  operation.  PLANNER-type 
antecedent  and  erase  theorems  could  be  built  out  of  such 
teams  of  demons. 

What  the  languages  for  research  in  artificial 
intelligence  lack  in  their  demon  mechanisms  are 
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Alerter  Binding 


Alerters,  as  treated  in  this  thesis,  are  oairs  of 
condition  and  proqram,  similar  in  form  to  PLANNER 
theorems  or  Dijkstra's  guarded  commands.  Morgan  (1970) 
has  dealt  with  the  subject  of  event  sequenced  proqrams  in 
some  detail,  concentrating  on  the  resolution  of  conflicts 
caused  by  attempts  to  update  a variable  simultaneously  by 
different  Droqrams.  The  aoproach  taken  here  differs  in 
that  the  alerters  run  conceptually  asynchronously  and  do 
not  require  the  update  to  be  delayed  until  the  proqram 
portion  of  the  alerter  has  run  to  completion. 


The  first  task  in  explaining  the  alertinq  mechanism 
is  to  sketch  the  range  of  possibilities  for  the  object  to 
which  the  alerter  can  be  bound.  I follow  the 
classif ication  of  Morqan  and  Buneman  (1975)  which  divides 
alerters  into  several  types  according  to  the  richness  of 
their  properties. 


A.  Binding  to  variables 

The  most  primitive  sort  of  binding  which  an  alerter 
could  have  is  at  the  level  of  variables,  that  is,  simple 
storage  locations.  I include  this  level  of  alerter 
binding  to  emphasize  how  the  more  elaborate  types  of 
bindings  depend  on  the  existence  of  records,  with  record 
classes  containing  multiple  instances  of  a record  type. 
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B.  Simple  Alertinq 

Simple  alertinq  applies  to  alerters  which  can  be 
bound  to  a single  record  in  the  database  in  order  to 
monitor  it. 


1.  monitoring  an  item,  i.e.  one  or  more  fields  of 
a record,  for  example  the  aqe  of  a particular 
student . 


2.  monitoring  a single  record  as  a whole,  for 
example  change  to  any  field  of  a bank  account 
record . 


3.  monitoring  a field  for  a record  type,  for 
example  the  age  field  in  any  record  of  the  student 
type. 


4.  monitoring  the  addition  of  a record  to  a set  of 
records. 


5.  monitoring  the  deletion  of  a record  from  a set 
of  records. 


6.  monitorinq  any  field  of  any  record,  for  example 
reporting  that  any  personnel  record  has  been 
modified  in  any  way. 
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C.  Structural  Alertinq 

!i 

I 

Alerters  can  monitor  the  structure  of  the  database, 
in  other  words  the  relations  between  records  in  terms  of 
set  ownership.  This  requires  at  a minimum  that  the 
alerter  be  bound  to  an  owner  record  as  well  as  an  owned 
record . 
i 

1.  Change  in  set  ownership  or  membership  of 
records.  For  example  a doctor  receives  a new 
patient  or  a company  a new  supplier. 

2.  Change  in  properties  of  the  set  as  a whole.  For 
example,  the  number  of  students  in  a class  exceeds 
30. 

3.  Change  in  fields  of  the  owned  record.  This  may 

arise  in  at  least  two  ways:  a doctor  may  acquire  a 

new  patient  with  measles  or  a patient  already  beinq 
treated  may  contract  measles. 


D.  Complex  Alerting 


Complex  alerting  covers  those  types  of  alerters 
which  require  an  even  more  holistic  point  of  view  in 
order  to  handle  the  interaction  between  user  and 
database . 

1.  Statistical  alerters.  For  example,  inform  the 
user  if  the  averaqe  bank  balance  of  all  accounts 
chanqes  by  more  than  a given  amount.  It  would  be  a 
simple  task  to  plan  for  the  system  to  keep  runninq 
counters  for  averaqe,  maximum,  minimum,  count  and 
other  simple  statistical  quantities,  but  it  is 
apparent  that  more  complicated  calculations  will 
require  complete  scans  of  the  database. 

2.  Alerters  which  monitor  transactions  over  time. 
For  example,  inform  the  user  whenever  a bank  balance 
drops  by  more  than  $10,000  in  any  24  hour  period. 
This  form  of  alerting  requires  that  a loq  be  kept  of 
all  transactions  for  the  24  hour  period. 

3.  Pattern  recognition.  This  type  of  alerter  would 
monitor  the  creation  of  a pattern  by  whatever  means 
that  occurs.  There  would  be  no  distinction  between 
changing  of  existinq  records  and  addition  of  new 
ones  if  they  give  rise  to  the  desired  pattern. 


4.  Time  based  alertinq.  Althounh  this  is  similar 
to  number  2.  the  distinction  is  that  the  alert  need 
not  be  siqnalled  immediately,  but  only  within 
suficient  time  to  be  useful.  Such  alerters  could 
deliver  reports  on  a weekly  schedule  for  example. 

5.  *!onitorinq  exDressions.  This  form  of  alertinq 
is  an  elaboration  of  the  simDler  forms  of  alertinq 
in  the  direction  of  providinq  Boolean  combinations 
of  conditions  on  the  alerter.  The  alerter  must 
therefore  be  bound  to  possibly  several  records  at 
once.  For  example,  the  user  might  want  to  know 
whenever  a stock  had  exceeded  its  previous  daily 
hiqh  and  sold  in  greater  volume  than  the  previous 
day. 

6.  Alertinq  on  the  structure  of  the  data  base.  The 
issue  here  is  to  alert  on  a chain  describable 
throuqh  the  schema  from  possibly  multiple  owners  to 
a record.  It  may  reauire  bindings  to  several 
records  at  the  same  time.  This  is  the  sort  of 
alerter  binding  reouired  by  requests  to  monitor  say 
the  age  of  the  qrandfather  of  some  individual,  where 
the  point  in  the  data  base  may  be  arbitrarily 
distant,  although  reachable. 
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The  issue  here  *s  that  when  the  demon  is  triqqered 
its  aiquments  may  no  lonqer  be  up-to-date  if  they  have 
been  modified  s»nce  the  demon  was  triqqered.  If  more 
than  one  orocessor  (human  or  computer)  has  been  alerted 
that,  say,  a fuel  level  was  too  low  or  some  service  was 
reouired,  one  of  the  processors  miqht  have  taken  action 
before  the  other,  so  the  second  must  retest  its  condition 
to  make  sure  that  the  action  is  still  needed.  The  issue 
here  is  to  alert  on  a chain  describable  throuqh  the 
schema  from  possibly  multiple  owners  to  a record.  It  may 
require  bindinqs  to  several  records  at  the  same  time. 
This  is  the  sort  of  alerter  binding  required  by  requests 
to  monitor  say  the  aqe  of  the  grandfather  of  some 
individual,  where  the  point  in  the  data  base  may  be 
arbitrarily  distant,  although  reachable. 


LDEMON  LISP  Alerter  System 
(and  a DAISY  interface) 

LDEMON  is  a system  consisting  of  two  packages,  one 
for  creating  and  updating  a simple  data  base,  and  the 
other  for  monitoring  changes  in  the  data  by  means  of 
procedures  known  as  demons. 

The  approach  taken  by  LDEMON  has  several  features  of 
interest  to  the  user.  First,  the  user  is  able  to  define 
new  record  classes  and  demons  interactively.  There  is  no 
need  to  plan  demons  at  the  time  of  creating  a new  record 
class,  as  would  be  necessary  with  a compiled  system.  The 
only  restriction  is  that  a demon  should  not  be  created 
prior  to  defining  all  relevant  record  classes. 

A second  point  is  that  data  bases  may  be  shared 
among  several  users,  within  DAISY,  for  instance.  Any  of 
the  users  may  add  new  record  classes,  new  demons,  new 
records,  or  updates  to  existing  records. 

Third,  even  though  LDEMON  is  not  at  all  a production 
system,  since  is  written  in  an  interpretive  language, 
LISP,  and  does  not  handle  data  bases  in  auxiliary 
storage,  nevertheless  it  is  an  efficient  approach  to 
processing  data  base  demons,  because  the  labor  involved 
in  monitoring  changes  is  of  the  order  of  the  number  of 
updates  and  is  independent  of  the  size  of  the  data  base. 
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As  a consequence,  the  approach  of  LDEMON  is  oarticularly 
useful  for  larqe  data  bases.  Finally,  the  record 
handlinq  facilities  of  LDEMON  provide  a set  of  primitives 
written  in  LISP  that  can  form  the  basis  for  buildinq 
other  experimental  data  base  systems,  as,  for  example, 
David  Root  has  done  in  writing  a relational  data  base 


languaqe  on  top  of  LDEMON 
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Record  Handlinq  Facilities 

LDEMON  provides  means  for  creating  record  classes, 
adding  new  records,  displaying  and  selecting  records,  and 
updating  the  contents  of  records. 


Creatinq  a record  class 

The  function  used  for  creatinq  a new  class  of 
records  is  DEF-RECTYPE,  with  the  name  of  the  record  for 
the  first  arqument,  followed  by  all  the  field  (or 
accessor)  names  of  that  record.  For  example, 

(DEF-RECTYPE  STUDENT  SCHOOL  AGE) 

creates  a new  record  class  STUDENT  with  accessors  SCHOOL 
and  AGE. 

DEF-RECTYPE  provides  the  user  with  a record  class 
predicate  function  and  one  accessor  function  for  each 
field.  In  the  example  here,  a new  function  STUDENT  has 
been  created  which  returns  T or  NIL  depending  on  whether 
its  single  arqument  is  or  is  not  a STUDENT  record.  In 
addition,  thue  have  been  created  two  accessor  functions, 
SCHOOL,  and  AGE,  which  select  the  SCHOOL  and  AGE  fields 
of  their  arqument.  The  record  class  predicate  and  the 
accessor  functions  all  take  one  arqument  and  may  be 
applied  either  to  a sinqle  record  or  a list  of  records. 
In  the  second  case  they  return  a list  of  results. 
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Thus,  if  there  is  a STUDENT  record  oointed  at  by  0, 
with  SCHOOL  field  PENN  and  AGE  field  20, 

(STUDENT  0) 
returns  T 

and 

(SCHOOL  Q) 
returns  PENN 

Besides  creating  these  auxiliary  functions, 
DEF-RECTYPE  defines  the  record  class  name  as  leqal  for 
use  in  addinq  new  records  and  updatinq  existing  ones. 

Addinq  new  records 

Two  functions  are  of  use  in  addinq  new  records  to  an 
LDEMON  “file"  (i.e.  list  of  records  corresponding  to  a 
record  class).  A "file"  is  created  by  addinq  new  records 
once  the  record  class  has  been  started. 

The  function  GENCONS  takes  as  arquments  a record 
class  name  followed  by  values  for  every  field  of  the 
record  class,  in  the  appropriate  order.  Accessor  or 
field  values  may  be  either  alphanumeric  (unauoted)  or 
numeric.  For  example. 
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(GENCONS  STUDENT  PENN  21) 

creates  a new  STUDENT  record  with  PENN  for  the  value  of 
SCHOOL,  and  21  for  the  value  of  AGE. 

The  effect  of  GENCONS  is  to  add  the  new  record  to 
the  front  of  the  current  list  of  records  kept  on  the 
RECORD  property  of  the  record  class  name. 

Another  function,  CREATE,  allows  the  user  to  create 
one  or  more  identical  records  . All  the  arquments  used 
by  GENCONS  follow  an  inteqer  for  the  number  of  times  the 
same  record  is  to  be  added  to  the  data  base.  For 
example , 

(CREATE  1 STUDENT  DREXEL  22) 

has  exactly  the  same  effect  as  (GENCONS  STUDENT  DREXEL 
22)  , while 

(CREATE  3 STUDENT  TEMPLE  23) 

will  create  three  records  with  TEMPLE  for  SCHOOL  and  23 
for  AGE. 


Displayinq  records 

The  function  DISPLAY  enables  the  user  to  display  all 
records  of  a qiven  record  class  or  all  values  of  a 
specified  field  of  a record  class.  The  first  arqument  of 
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DISPLAY  is  a record  cldss  ndme  dnd  the  optiondl  second 
dtqument  is  d accessor  or  field  ndme.  For  exdmole,  if 
(GENCONS  STUDENT  PENN  21)  dnd  (GENCONS  STUDENT 
DREXEL  22)  hdve  been  executed, 

(DISPLAY  STUDENT) 

returns  (((STUDENT)  DREXEL  22)  ((STUDENT)  PENN  21)) 

dnd  (DISPLAY  STUDENT  AGE) 

returns  (22  21) 

From  the  description  of  the  record  class  predicate 
and  accessor  functions  it  should  be  clear  how 
(STUDENT  (DISPLAY  STUDENT)) 
returns  (T  T) 

and  (AGE  (DISPLAY  STUDENT)) 

returns  (22  21) 

since  DISPLAY  returns  the  list  of  records  in  a record 

class  when  applied  to  a record  class  name. 

Selectinq  records 

The  function  RECORD  selects  a particular  record  from 
a record  class.  The  first  arqument.  is  an  inteqer 
referring  to  the  reverse  order  of  accession  of  the  record 

and  the  second  argument  is  a record  class  name.  For 

example , 


(RECORD  1 STUDENT) 
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returns  ((STUDENT)  DREXEL  22) 

The  user  of  LDEMON  may  prefer  to  keep  explicit 
pointers  to  records  by  doinq  something  like 

(SETQ  FRED  (GENCONS  STUDENT  HAVERFORD  19)) 

at  the  time  of  creating  a record. 


Updating  records 

To  chanqe  field  values,  the  function  SET-VAL  is  used. 
The  first  argument  must  specify  a sinqle  record  by  means 
of  a pointer  to  the  record  in  an  expression  like 

(EVAL  (QUOTE  <pointer>)) 

or  a selecting  expression  which  points  to  a sinqle 
record.  The  second  arqument  is  a record  class  name,  and 
the  third  argument  is  a field  value.  For  example, 

(SET-VAL  (RECORD  1 STUDENT)  SCHOOL  CORNELL) 

Will  change  the  value  of  the  SCHOOL  field  to  CORNELL. 

It  should  be  noted  that  all  records  are  changed  in 
place,  so  no  new  space  is  acquired  by  SET-VAL. 


i 


Demons 

! 

I 

Defininq  new  demons 
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LDEMON  adds  two  new  functions  (from  the  user's  Doint 
of  view)  and  two  special  keywords  to  the  apparatus 
already  in  LISP  for  defininq  new  functions  in  order  to 
define  demons.  This  is  best  illustrated  by  an  example. 
For  instance,  assuminq  that  there  exists  a record  class 
BANK-ACCOUNT,  with  fields  3ALANCE  and  NAME,  and  the  demon 
is  supposed  to  print  the  name  of  any  depositor  whose  bank 
account  balance  falls  below  200  dollars.  The  demon  to  do 
this  can  be  written  as 

(DEMON  OVERDRAWN  (X) 

(JCOND  ( ( LESSP  (BALANCE  X)  200) 

(PRINT  (NAME  X) ) 

(PRINC  (QUOTE  "IS  OVERDRAWN")) 

) ) ) 

As  seen  from  this  example,  a demon  is  defined  much 
like  a LISP  function,  with  a name,  OVERDRAWN,  an  arqument 
list,  (X)  , and  a function  body.  The  arqument  list 
contains  only  one  variable,  X , which  is  bound 
conceptually  to  all  records  of  any  record  class  which  has 
both  BALANCE  and  NAME  amonq  its  fields.  It  should  be 
emphasized  that  the  bindinq  is  not  to  a variable  or  an 


classes  containing  multiple  instances  of  a record  type 
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instance  of  a record,  but  to  a set  of  records.  In  other 
words,  the  demon  OVERDRAWN  should  be  read  as  if  it 
constantly  monitored  all  BANK-ACCOUNT  records  (and  the 
records  of  any  other  record  class  that  had  BALANCE  and 
NAME  fields)  and  printed  the  NAME  field  of  any  such 
record  whenever  its  BALANCE  field  went  below  200. 

The  JCOND  construction  used  here  can  be  thouqht  of 
as  a natural  refinement  for  demons  of  the  LISP  CCND. 
Ordinarily,  demons  are  activated  only  when  chanqes  have 
taken  place  in  the  data  base.  It  is  both  unnecessary  and 
impractical  for  a demon  to  perform  its  action  continually 
as  lonq  as  its  condition  is  true.  Therefore,  instead  of 
testino  a condition  with  a COND,  LDEMON  uses  the  JCOND  to 
perform  the  action  only  when  a condition  has  just  become 
true  which  was  not  true  before.  In  the  example,  this 
means  that  the  name  of  a depositor  is  printed  only  once 
whenever  his  bank  account  becomes  too  low.  If  a COND  had 
been  used  instead  of  the  JCOND,  the  name  would  be  printed 
every  time  the  balance  changed  as  long  as  it  was  below 
200  dollars. 

The  demon  OVERDRAWN  is  processed  by  the  DEMON 
• function  to  form  a LISP  function  called  OVERDRAWN,  which 

is  then  added  to  the  DEMON  property  of  all  the  field 
names.  The  LISP  function  looks  like  this: 
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(LAMBDA  (X) 

(COND  ((AND  (LESS  P (BALANCE  OLD)  200) 

(NOT  (LESS P (BALANCE  NEW)  200))) 

(PRINT  (NAME  X) ) 

(PRINC  (QUOTE  “IS  OVERDRAWN")) 

) ) ) 

The  argument  variable  X in  the  first  oredicate  of  the 
JCOND  has  been  replaced  by  OLD  and  NhW  in  the  course  of 
transforming  the  JCOND  into  an  ordinary  LISP  COND.  These 
two  new  keywords  are  introduced  to  refer  to  the  record 
before  and  after  it  has  been  updated.  OLD  and  NEW  may 
also  be  used  in  the  action  Dart  of  the  demon.  The  old 
balance  could  be  printed,  for  instance,  by  writing 

(PRINT  (BALANCE  OLD) ) 

In  more  detail,  the  DEMON  function  takes  three  or 
more  arguments  of  which  the  first  is  the  name  of  the 
demon,  the  second  is  the  arqument  list,  which  may  contain 
only  one  variable,  and  the  third  and  further  arguments 
are  any  LISP  expressions.  The  third  or  further  arguments 
must  contain  an  accessor  expression  which  refers  to  a 
field  of  some  existing  record  class,  like 
(NAME  X) 

and  the  argument  of  that  accessor  must  be  either  the 
variable  in  the  argument  list,  or  OLD,  or  NEW.  OLD  or 


the  argument  list  variable  refer  to  the  value  of  the 
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field  before  the  update,  and  NEW  refers  to  the  value 
after  the  update.  For  example,  if  a new  record  class  A 
has  been  defined,  with  fields  B and  C,  the  followinq 
could  be  written, 

(DEMON  A 1 (X)  (PRINT  (B  X))) 

which  will  cause  the  old  value  of  any  B field  to  be 
Drinted  whenever  it  has  been  updated  by  a call  to 
SET-VAL. 


JCOND 

The  JCOND  (for  Just  chanqed  COND)  is  the 
construction  which  allows  a demon  to  reqister  a chanqe 
that  has  just  happened.  Its  syntax  is  similar  to  that  of 
a COND  with  a sinqle  pr ed icate-act ion  pair.  However, 
unlike  the  COND,  the  JCOND  has  only  one  alternative;  if 
the  predicate  for  this  condition  is  not  true,  the  demon 
simply  does  not  perform  its  action. 

(JCOND  (<Dredicate>  <action>)) 

Using  the  same  example  as  before,  and  assuminq  that  B is 
a numeric  field,  it  would  be  possible  to  write 

(DEMON  A2  (X)  (JCOND  ((GREATERP  (B  X)  7) 

(PRINT  (C  NEW) ) ) ) ) 

to  create  a demon  which  would  print  the  value  of  the  C 
field  (OLD,  NEW,  or  X mean  the  same  here)  , whenever  the 
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value  of 

the  B field 

has  been 

chanqed  to  a value 

larqer 

than  7 

from  a value 

that  was  not 

larqer.  The  i 

moor  ta  n t 

Doint  to 

note  here  is 

that  a 

JCOND 

is  converted 

without 

chanqe 

into  a COND 

unless 

it 

involves  an 

accessor 

express! 

on  with  the 

demon 

arqument  variable 

as  its 

ar qument 

. This  is  why  the  oredicate  is  (B  X) 

in  the 

example . 

The  predicate  may  be  of  any  complexity,  provided  it 
follows  these  rules,  and  a seciuence  of  actions  may  follow 
the  predicate,  as  in  a COND  in  UCI  LISP. 

At  the  oresent  time  demons  are  not  exolicitly 
aualified  by  record  classes;  the  field  names  in  the 
action  and  condition  oortions  of  the  demon  imolicitly 
restrict  the  set  of  record  classes.  This  can  cause 
difficulties  if  two  record  classes  share  a field  name, 
since  both  record  classes  will  cause  a demon  to  be 
activated  even  thouqh  only  one  was  intended.  However, 
the  user  is  always  able  to  limit  the  demon  to  one  record 
class  by  usino  the  record  class  name  as  a oredicate. 
This  was  a desiqn  decision  that  could  warrant  chanqinq 
for  different  types  of  user  interaction  with  the  data 


base . 
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The  Daisy  Interface 


LDEMON  allows  the  user  to  create  simplified  demons 
called  alerters  to  observe  updates  of  a data  base.  The 
LISP  user,  however,  has  available  the  full  power  of 
demons  in  LISP,  and  these  are  essentially  anythinn  that 
can  be  pr  on  rammed  j.n  LISP,  as  can  be  seen  from  the 
previous  section. 


The  ALERT  function 

The  DAISY  user  needs  to  know  only  the  ALERT  function 
to  specify  simple  alerters  which  are  trigqered  by  a 
single  condition  on  some  field  value  in  a record.  The 
ALERT  function  takes  as  first  argument  a name  for  the 
alerter  to  be  created;  as  second  argument  a condition  on 
whether  the  alerter  is  to  be  trigqered;  and  as  optional 
third  and  further  arguments  LISP  expressions  to  do 
whatever  actions  are  required.  The  condition  may  be  any 
of  the  following: 

(CHANGE  <f ield  name>) 

or  (<field  name>  <relation>  <field  value>) 

where  <relation>  is  one  of  EQUAL,  GREATERP,  or  LESSP. 
For  example, 
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(ALERT  SCHOOL-CHANGE  (CHANGE  SCHOOL) 

(PRINT  AGE) ) 

which  creates  an  alerter  SCHOOL-CHANGE  to  Drint  the  value 
of  the  SCHOOL  field  in  any  STUDENT  record  which  has  just 
had  its  SCHOOL  field  updated. 

If  this  alerter  is  compared  with  the  demons  of  the 
last  section,  it  will  be  seen  that  the  demon  arqument 
variable,  OLD,  and  NEW  are  not  used.  The  arquments  of 
the  accessors  used  in  the  alerter  are  filled  in  by  ALERT, 
which  creates  a call  to  DEMON  as  the  followinq  example 
will  show. 


(ALERT  HAVER  (SCHOOL  EQUAL  HAVERFORD) 
(PRINT  AGE) ) 


becomes 


(DEMON  HAVER  (X)  (JCOND 

((EQUAL  (SCHOOL  X)  (QUOTE  HAVERFORD)) 

(DAISYWRITE  "ALERT  " (QUOTE  HAVER)) 
(PRINT  (SCHOOL  NEW) ) 

) ) ) 

which  turns  into  the  function  HAVER  with  definition 
(LAMBDA  (X) 

(COND  ((OR  (STUDENT  X)) 

(COND 

((AND  (EQUAL  (SCHOOL  NEW) 

(QUOTE  HAVERFORD)) 


(NOT  (EQUAL  (SCHOOL  OLD) 
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) ) 


(QUOTE  HAVERFORD)) 


(DAISYWRITE  "ALERT  " 

(QUOTE  HAVER)) 

(PRINT  (SCHOOL  NEW)) 

))  ))  ) 

The  DAISYWRITE  expressions  which  are  created  by  ALERT 
tell  the  DAISY  user  which  alerter  has  been  triqgered. 
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Records  and  Functions  in  SANDL 


In  contrast  with  the 
records  consisting  of 
management  system  is  based 
DBTG  report  translated 
functional  format. 


LDEMON  system  which  handles 
data  items,  the  SANDL  data 
on  the  semantics  behind  the 
into  a more  LlSP-comoatible 


In  DBTG  there  are  three  basic  relations  between 
objects:  the  one-to-one  relation  between  records  and 
their  fields,  the  one-to-many  relations  between  owner 
record  and  the  set  of  records  owned,  and  a manv-to-many 
relation  between  records  which  is  accomplished  by  the 
so-called  confluent  hierarchy  in  which  a record  owned  bv 
several  records  simultaneously  in  the  one-to-may  mode  is 
used  to  embody  the  manv-to-may  relation  between  all  the 
owners . 

In  the  SANDL  system  the  first  type  of  relation  is 
thought  of  as  a function  from  record  to  field.  The 
function  has  the  same  name  as  the  field.  Since  the  field 
names  are  not  reouired  to  be  unioue  in  the  schema,  the 
field  function  is  in  fact  a family  of  functions  from 
which  the  appropriate  one  is  chosen  according  to  the 
record  class  of  the  argument. 


ways : 


The  second  type  of  relation  is  treated  in  two 
as  function  from  record  to  owned  set  with  the  name  of  the 
record  field  used  as  the  set  accessinq  function.  (This 
corresponds  to  the  downward  arrow  in  the  diaqram.)  It  is 
also  treated  as  a function  from  an  owned  record  to  its 
owner , in  which  case  the  owner  record  class  is  the 
function  name.  There  is  a possibility  of  ambiquity 

however  if  a record  can  be  owned  be  the  same  record  in 
two  different  sets.  The  owner  record  need  not  be 
immediately  above  the  owned  record  since  the  system  can 
automat ical 1 y refer  to  the  schema  to  find  an  access  chain 
from  owner  to  set  member. 

A particularly  qood  point  in  favor  of  the  functional 
syntax  is  how  well  it  matches  ordinary  Enqlish  lanquaqe 
usaqe  in  accessinq  data.  Instead  of  spellinq  out  an 
access  chain  to  the  desired  data  object,  the  user  can 
much  more  simply  use 

field  ( record  (object)) 

as  in  NAME  (FATHER  (X))  which  reads  as  NAME  of  FATHER  of 
X.  While  this  parallelism  between  Enqlish  and  functional 
notation  miqht  be  painfully  obvious,  it  does  pose  a 
question  why  a more  proqrammatic  form  of  data  access  by  a 
chain  of  pointers  is  not  used.  Perhaps  human  coqnitive 
data  manaqement  is  much  better  suited  to  dealinq  with 
intentional  processes  rather  than  extensional  ones  such 


as  set  membership. 
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The  many-to-manv  relation  is  d hit  trickier  to 
handle  within  d functiondl  frdmewotk.  In  the 
doctor-Ddtient  reldtion  shown  below,  where  d doctor  hds 
mdny  pdtients  dnd  d Ddtient,  many  doctors  dll  connected 
throuqh  d confluent  record  CASE,  the  best  thdt  cdn  be 
done  is  to  return  the  set  of  pdtients  for  the  doctor  or 
the  set  of  doctors  for  the  Ddtient. 

In  the  dbove  discussion,  I emphasize  thdt  set  names 
dre  simply  fields  thdt  dccess  sets.  For  the  most  part 
they  are  not  needed  in  accessinq  records  exceDt  in  cases 
of  ambiquity  and  one-to-many  relations. 
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Implementation 


This  portion  of  the  thesis  provides  the 
specifications  of  a system  for  alertinq  on  network  data 
bases.  SANDL  is  an  extension  of  an  earlier  system, 
LDEMON , a data  base  management  system  written  in  LISP 
with  a capability  for  monitorinq  chanqes  in  the  data  bv 
means  of  procedures  which  aopear  to  be  continuously 
active,  called  demons. 

Statement  of  the  Problem 

The  desiqn  of  SANDL  allows  demons  (also  called 
alerters)  to  be  placed  on  an  updatable  network  data  base 
manaqement  system  which  has  the  power  of  the  basic 
semantic  notions  detailed  in  the  CODASYL  report  on  DBTG , 
without  any  attempt  to  deal  with  specifics  of 
implementation.  What  will  be  new  to  LDEMON  is  the  DBTG 


concept  of  set  ownership  and  the  ability  to  create  demons 
which  monitor  chanqes  in  the  composition  of  a set. 


The  qeneral  bias  throuqhout  this  paper  has  been  to 
avoid  as  far  as  possible  any  need  to  refer  to  sets 
throuqh  set  names,  by  an  intelliqent  use  of  a schema 
which  stores  a representation  of  the  hierarchy  of  record 
types.  Thus,  althouqh  a set  may  always  be  referred  to 
unambiqously  throuqh  a field  of  type  SET  in  the  owner 
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Data  Definition  Lanquaqe 


The  datd  definition  lanquaqe  (DDL)  allows  the  user 
to  specify  what  types  of  records  may  be  placed  in  the 
data  base,  with  what  fields,  and  what  domain  (or  type)  of 
field  values.  In  addition,  the  DDL  specifies  set 
ownership  and  set  membership  of  records.  In  contrast 
with  the  situation  in  DBTG,  the  DDL  of  SANDL  is  dynamic. 


In  order  to  inform  the  data  base  manaqement  system 
as  well  as  the  demon  processor  about  the  current  state  of 
the  record  hierarchy,  a special  directed  qraph  known  as 
the  schema  is  kept  in  memory  and  is  updated  by  the  DDL. 
The  schema  contains  information  on  all  record  classes, 
their  field  names  and  ranqe  of  values,  as  well  as  set 
owner  - set  member  relations.  In  DBTG,  one  can  naturally 
construct  three  distinct  sorts  of  relations  between 
Pieces  of  data;  a one-to-one  relation  between  a record 
and  its  constituent  fields,  a one-to-many  relation 
between  an  owner  record  and  the  set  of  records  owned  by 
it,  and  a manv-to-many  relation  (called  a confluent 
hierarchy)  between  records  which  share  owned  records 


between  them 
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The  schema  is  modifiable  and  means  are  provided  for 
disnlayinq  it  to  the  user.  Saymq  that  the  schema  is 
modifiable  means  that  new  record  tyoes  can  be  added  to 
the  data  base  while  the  system  is  runn.nq  and  additional 
fields  can  be  declared  for  already  existinq  record  types. 
Chanqes  in  the  schema  will  of  course  be  constrained  by 
the  necessity  of  not  destroymq  entire  sets  of  records  bv 
destroyin  q their  record  type. 

Creatinq  new  record  types 

In  LDEMON  a new  record  type  is  created  by  a call  to 
the  function  DEF-RECTyPE  of  the  form 

(DEF-RECTYPE  STUDENT  SCHOOL  AGE) 

in  order  to  define  a new  record  type  STUDENT  with  fields 
SCHOOL  and  AGE.  SANDL  replaces  this  form  of  the  function 
call  by  addinq  arguments  for  the  owner  record  types  and 
the  type  of  each  field. 

For  example, 

(DEF-RECTYPE  STUDENT  (DORMITORY)  SCHOOL  CHARACTER 

AGE  NUMBER  ) 

where  DORMITORY  is  the  record  type  of  the  only  owner 
record,  SCHOOL  is  declared  of  type  CHARACTER,  and  AGE  of 


type  NUMBER 
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DEF-RECTYPE  adds  the  STUDENT  record  type  to  the  data 
base  schema  and  Diaces  this  record  in  the  relationship  of 
set  member  to  the  owner  record  class  DORMITORY.  In  DBTG 
terms. 


Furthermore,  selector  functions  are  created  corresDondinq 
to  each  of  the  fields  SCHOOL  and  AGE.  Unlike  in  LDEMON , 
the  function  STUDENT,  also  created  by  DEF-RECTYPE,  is  not 
a record  type  predicate  but  a selector  function  that 
yields  the  set  of  students  when  applied  to  a DORMITORY 
record . 

The  syntax  of  the  DEF-RECTYPE  function  call  is 

(DEF-RECTYPE  Crecord  type> 

<list  of  owner  record  types> 

<field  and  type>*  ) 

and  <field  and  type>  is 


< field > <type> 


CHARACTER  (with  no  lenqth  ciudl  if icat ion ) 

SET 


which  may  be  abbreviated  to  NUM,  CHAR,  and  SET. 

In  the  example  below,  the  record  type  DORMITORY  is 
defined  with  some  field  of  type  SET  which  is  to  own  the 
STUDENT  records.  This  is  an  intentional  deoarture  from 
DBTG  and  combines  the  relationship  of  data-items  to  a 
record  with  that  of  sets  owned  by  the  record.  If 
DORMITORY  is  considered  to  be  a top-level  record  type  in 
the  schema,  i.e.  a member  of  no  set  owned  by  any  other 
record,  its  owner  is  simply  the  null  set  of  record  types, 
NIL.  In  this  case  the  record  type  DORMITORY  is  defined 
by 

(DEF-RECTYPE  DORMITORY  NIL  RESIDENTS  SET 

NAME  CHARACTER) 
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Data  Mdndqement  Lanquaqe 

The  ddtd  manaqement  ldnqudqe  ( DM  L ) allows  the 
credtion,  deletion,  dnd  modification  of  records  contdined 
in  sets  owned  by  other  records.  In  addition,  functions 
are  to  be  provided  that  select  subsets  of  records  that 
meet  specified  conditions. 

Addinq  new  records 

To  add  a new  record  to  the  data  base  reauires  that 
the  record  type  and  the  owner  record  be  supolied, 
toqether  with  the  appropriate  field  values  for  each  field 
defined  for  the  record  type.  In  other  words,  the 
arquments  of  the  function  to  do  this,  INSERT,  are  the 
same  as  those  for  GENCONS  in  LDEMON , except  for  the 
addition  of  the  owner  record  as  an  arqument.  For 
example,  if  DOC  1 is  a particular  DOCTOR  record,  where  the 
DOCTOR  record  is  defined  as  owninq  a set  of  records,  and 
PATIENT  has  been  defined  by 

(DEF-RECTYPE  PATIENT  (DOCTOR)  AGE  NUMBER 

SEX  CHARACTER 
NAME  CHARACTER  ) 

then 

(INSERT  PATIENT  DOC1  20  MALE  JONES  ) 


will  insert  a PATIENT  record  into  the  set  of  patients 


Paqe  40 


owned  by  the  DOC1  record.  DOC1  serves  as  a unioue 

identifier  of  some  particular  DOCTOR  record.  In  this 

implementation  it  is  a pointer  to  the  specified  record, 
but  it  can  be  thouqht  of  as  an  identifyina  kev.  The 
value  of  the  INSERT  function  is  the  newly  created  record. 
If  the  record  to  be  inserted  belonqs  to  a ton-level 
record  type  then  the  function  needs  no  owner  record 
arqument . 

The  syntax  of  INSERT  is 

(INSERT  <record  type>  <field  value>*  ) 

or 

(INSERT  <record  type>  <owner  record> 

<field  value>*  ) 

where  there  must  be  as  many  field  values  as  there  are 
fields  in  the  record  type  and  they  must  aqree  in  tyoe  and 
order  with  their  definitions  at  the  time  of  defininq  the 
record  type. 

Deletinq  records 

A record  can  be  deleted  from  the  data  base  bv  the 
function  DELETE  with  value  NIL.  When  a record  is  deleted 
it  is  removed  from  all  sets  to  which  it  belonqs.  The 
syntax  of  the  function  call  is  simoly 
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(DELETE  <record>) 

UDdatinq  records 

Values  of  NUMBER  and  CHARACTER  fields  may  be  chanqed 
by  the  function  SET-VAL,  with  the  syntax 

(SET-VAL  <record>  <field  name>  <field  value>) 

where  <record>  is  any  record  in  the  database  with  the 
data  item  <field  name>.  No  owner  record  is  needed.  A 
further  function,  SET-VALUES,  chanqes  all  the  fields  of  a 
record,  leavinq  those  with  <field  value>  equal  to 
unchanqed  . 

(SET-VALUES  <record  > <field  value>*  ) 

SET-VALUES  must  have  as  many  field  values  as  the  number 
of  fields  in  the  record  type. 

SET-VALUES  is  provided  as  a convenience  for  chanqinq 
several  fields  of  a record  at  the  same  time. 

Movinq  records  between  sets 

In  order  to  move  a sinqle  record  from  one  set  to 
another,  as  for  example  transferrinq  a case  from  one 
doctor  to  another,  the  function  TRANSFER  is  used,  with 


the  syntax 
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(TRANSFER  <record>  <from  owner  record> 

<to  owner  record>  ) 


Selectinq  records  from  d set 

Three  functions  to  select  a subset  of  records  or 
aoply  d function  to  dll  elements  of  d set  dre  SELECT, 
SELECT-ONE,  dnd  MAPSET.  Their  syntdx  is 

(SELECT  <predicate>  <set>) 

(SELECT-ONE  <predicdte>  <set>) 

(MAPSET  <function>  <set>) 

where  <set>  is  a set  of  records,  <predicdte>  is  a 
oredicdte  of  one  drqument  thdt  evdludtes  to  T or  NIL  when 
dpplied  to  d sinole  record,  dnd  <function>  is  d function 
or  ldmbdd  expression  of  one  dr  oilmen  t . For  exdmole,  if 
SOMESET  is  d set  of  cecoL'lr  with  a field  NAME  of  tvoe 
CHARACTER, 

(SELECT  (QUOTE  (LAMBDA  (X)  (EQ  (NAME  X) 

(QUOTE  SMITH) ) ) ) 

SOMESET  ) 

will  return  dS  its  vdlue  thdt  subset  of  SOMESET  whose 


NAMES  dre  SMITH 


SELECT-ONE  returns  that  unique  record  which 
satisfies  the  Dredicate;  if  more  than  one  exists,  the 
value  returned  is  NIL.  The  main  use  for  SELECT-ONE  is  to 
retrieve  items  from  record  types  with  uniaue  keys. 

The  function  MAPSET  apolies  the  function  to  every 
record  in  the  set  and  returns  NIL.  It  could  be  used  for 
its  effect,  chanqinq  the  value  of  some  field  for  every 
record  in  a set,  for  example. 

By  applyinq  these  functions  to  sets,  exDlicit  loops 
become  unnecessary  for  traversinq  a data  base.  This 
should  be  compared  with  the  non-procedural  approach  taken 
with  the  HI-IQ  retrieval  lanquage  in  Rob  Gerritsen's 
dissertation,  which  creates  an  access  path  for  findinq 
the  requested  data.  A simple  example  using  the  PATIENT 
record  type  defined  above  is  to  find  the  ages  of  all  male 
patients  of  a doctor  whose  record  is  DOC1.  All  that  is 
needed  is 

(AGE  (SELECT  (QUOTE  (LAMBDA  (X) 

(EQ  (SEX  X) 

(QUOTE  MALE) ) ) ) 


(PATIENT  DOC  1 ) ) ) 


The  ideas  presented  here  qo  beyond  those  of  LDEMON 
in  two  Dtincipal  ways.  Demons  are  used  to  monitor 
records  within  sets  owned  by  other  records,  and  the 
schedul inq  of  the  processinq  of  demons  is  more  elaborate. 

In  LDEMON,  demons  are  used  to  take  specific  action 
whenever  any  member  of  a record  tyne  has  its  fields 
modified.  SANDL  adds  the  ability  of  demons  to  watch  for 
chanqes  in  the  set  of  records  owned  by  a qiven  record 
type.  In  other  words,  demons  in  LDEMON  are  similar  to 
the  IFMODIFIED  demons  of  SANDL,  while  IFADDED  and 
I FREMOVED  demons  are  completely  new. 

In  LDEMON  a demon  has  a sinale  arqument  variable 
which  is  bound  to  whatever  record  triqqers  the  demon.  In 
qeneral,  demons  monitorinq  sets  bind  at  least  two 
arquments,  one  for  the  record  in  the  set,  the  second  for 
the  record  owninq  the  set.  The  one  exception  is  that 
top-level  records  are  not  owned  by  any  record,  so  the 
DBTG  schema 


DOCTOR 


corresponds  to  a demon  arqument  list 
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(DOCTOR  X) 

The  decision  was  made  in  LDEMON  to  execute  the 
action  of  a demon  before  the  update  which  triqqered  the 
demon.  For  demons  used  as  alerters  (i.e.  without  any 
effect  on  the  data  base)  this  seems  to  have  been  a bad 
choice,  since  the  update  itself  is  delayed  until  all 
relevant  demons  have  been  checked  and  those  triqqered 
have  been  executed.  SANDL  therefore  d ist inquishes  two 
types  of  demons:  what  will  be  called  fa il  demons,  and 

non-fail  demons.  A fail  demon  will  be  activated 
immediately  upon  beinq  triqqered,  while  a non-fail  demon 
waits  until  after  a chanqe  to  the  data  base  has  taken 
place.  The  fail  demons  can  be  used  to  send  messaqes 
that,  say,  an  illeqal  update  has  been  attempted,  or  to 
enforce  data  inteqrity,  for  example  by  preventinq  any 
field  from  chanqinq  to  a value  of  the  wronq  tvoe. 

Demon  syntax 

The  syntax  for  creatinq  a demon  is 

(<demon  type>  <demon  name>  <arqument  list>  <bodv>) 
or 

(<demon  type>  <demon  name>  FAIL  <arqument  list> 
<body> ) 

where  <demon  type>  is  IFADDED,  IFREHOVED,  or  IFMODI FIED, 
and  <body>  is  any  sequence  of  LISP  expressions. 
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The  <arqument  list>  is  either 

(Crecord  cldss>  <vdridble  ndine>  ) 
or 


(<record  cldss>  Cvdridble  name>  <arqument  list>*  ) 


To  illustrate  the  use  of  arqument  lists  compdre  the 
DBTG  structure 


with  the  drqument  list 

(CASE  U (DOCTOR  V (HOSPITAL  W) ) 

(PATIENT  X (HOSPITAL  Y))) 

Note  the  two  seodrate  bindinqs  of  HOSPITAL  records  to  the 
vdridbles  W dnd  Y.  The  reason  for  this  is  that  there  is 
no  way  to  exclude  the  possibility  of  two  different 
HOSPITAL  records  leadinq  throuqh  seoarate  ownership 
chains  to  a particular  CASE  record.  If  it  is  essential 
that  records  X and  Y be  the  same,  this  must  be  tested  in 
the  body  of  the  demon. 
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The  lowest  record  class  in  the  schema  is  placed 
first  in  the  arqument  list,  so  the  schema  is  to  be  read 
uowards  in  writinq  the  arqument  list. 
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JCOND 

The  JCOND  construction  for  changes  which  have  iust 
occurred  is  carried  over  from  LDEMON  in  the  IFMODIFIED 
demon.  Only  the  COND  (the  ordinary  LISP  " IF -THEN -ELSE" 
construction)  is  meaninqful  for  IFADDED  and  I FREMOVED 
demons,  since  in  these  cases  there  is  no  distinction  to 
be  made  between  old  and  new  versions  of  the  record. 

For  the  IFMODIFIED  demon  the  convention  for 
d ist inquish inq  old  versus  new  versions  of  a record  is  to 
prefix  the  variable  with  for  old  and  '+'  for  new.  In 
this  way 


< 


(AGE  -X) 

would  stand  for  the  value  of  the  AGE  field  of  the  record 
X before  an  update.  If  there  is  no  ambiguity  the  '+'  and 
prefixes  are  not  needed  and  the  JCOND  always  uses  the 
unadorned  variable  in  its  test. 
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Some  examples  of  demons 

If  the  DBTG  schema  is 


CASE  has  a field  DIAGNOSIS,  and  DOCTOR  has  a field  NAME. 
An  expression  to  orint  the  name  of  any  doctor  who  has  a 
patient  who  contracts  measles  is: 

(IFMODIFIED  Ml  (CASE  X (DOCTOR  Y)  ) 

( JCOND  ((EQ  (DIAGNOSIS  X)  (QUOTE  MEASLES)) 
(PRINT  (NAME  Y) ) ) ) ) 

However,  to  print  the  name  of  any  doctor  who  qets  a 
Datient  who  has  measles  is: 

(IFADDED  Al  (CASE  X (DOCTOR  Y)) 

(COND  ((EQ  (DIAGNOSIS  X)  (QUOTE  MEASLES)) 

(PRINT  (NAME  Y) ) ) ) ) 

A more  complicated  example  is  to  reoort  the  name  of 
any  department  if  the  proportion  of  female  staff  falls 
below  25%. 
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In  this  case  the  schema  is 


DEPT  has  fields  NUM-STAFF  and  PROPORTION-FEMALE,  and 
EMPLOYEE  has  a field  SEX.  Then  the  oroblem  is  solved  by 
means  of  three  demons. 


First,  the  table  below  qives  the  chanqes  to 
PROPORTION-FEMALE  (reoresented  by  P)  and  NUM-STAFF 
(reoresented  bv  N). 


Add 


Remove 


EmDlovee 

Female 

P :=  ( (P*N)+1)/(N+1) 

N :=  N+l 

P :=  ( (P*N)-1)/(N-1) 

N : = N-l 


Mai  e 

P :=  ( P*N ) / (N+l ) 
N : = N + l 

P : = (P*N) /(N-l) 
N : = N-l 


( I FA DDE D A 2 (EMPLOYEE  X (DEPT  Y)) 

(COND  ((E0  (SEX  X)  (QUOTE  FEMALE)) 

(SET-VAL  Y PROPORTION-FEMALE 
(DIVIDE  (ADDl  (TIMES 

(PROPORTION-FEMALE  Y) 


(NUM-STAFF  Y))) 
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1 


(ADD 1 (NUM-STAFF  Y ) ) ) ) ) 

(F  (SET-VAL  Y PROPORTION-FEMALE 
(DIVIDE  (TIMES 

(PROPORTION-FEMALE  Y) 
(NUM-STAFF  Y))) 

(ADD1  (NUM-STAFF  Y ) ) ) ) ) 
(SET-VAL  Y NUM-STAFF  ( A DD 1 (NUMSTAFF  Y ) ) ) ) 

( I FREMOVED  R2  (EMPLOYEE  X (DEPT  Y)) 

(COND  ((EQ  (SEX  X)  (OUOTE  FEMALE)) 

(SET-VAL  Y PROPORTION-FEMA LE 
(DIVIDE  (SUBl  (TIMES 

(PROPORTION-FEMM  Y) 
(NUM-STAFF  Y) ) ) 

(SUB1  (NUM-STAFF  Y ) ) ) ) > 

(T  (SET-VAL  Y PROPORTION-FEMALE 
(DIVIDE  (TIMES 

(PROPORTION-FEMALE  Y) 
(NUM-STAFF  Y) ) ) 

(SUB  1 (NUM-STAFF  Y) ) ) ) ) 
(SET-VAL  Y NUM-STAFF  (SUBl  (NUMSTAFF  Y)))) 

(IFMODIFIED  M2  (DEPT  W (UNIVERSAL  X)) 

( JCOND  ( ( LESS P (PROPORTION-FEMALE  W)  .25) 


(PRINT  (NAME  W) ) )) 
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This  example  shows  how  demons  can  be  used  to  monitor 
average,  maximum,  minimum,  and  count  of  a set.  IFADDED 
and  I FREMOVED  demons  must  UDdate  fields  in  the  owner 
record  and  an  IFMODIFIED  demon  watches  for  changes  in 
these  fields. 


•i 
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